Subject: Capabilities

From: [email-masked] (PNGacek)
Date: Thu, 15 Jul 93 07:48:23 MDT

Capabilities Exchange 7/15

Use of UDP

I am strongly opposed to using UDP as the vehicle to exchange 
capabilities. It makes it far more difficult to decouple DLSw from a 
transport and migrate to TP4, HPR or whatever. 

If it transpires that capabilities exchange info indicates that a 
different set of TCP connection parameters are required than the 
currently used, then take down the existing one and bring up one that 
does meet the requirements.

Name Server

Glad to see the Directory Service function has resurfaced. Very few 
people  checked it off on the feature matrix and when I raised it at the 
last AIW meeting it was happily dropped (under protest from Robin 
Layland). I personally like a Name Server/Directory Service. Something 
simple is required. I think we need a record format to define all the 
DLSw switch network addresses (possibly in a given domain).

One observation worth noting is that the quantity of configuration varies 
based on the type of traffic carried over a DLSw cloud. For dependent LU 
(3270 and 5250) then typically each controller attached DLSw will be 
attached to only a small set of other DLSw switches (i.e. those attached 
to hosts (S/370 or AS/400 type). For independent LU (LU 6.2) traffic, 
more mesh connectivity is required and hence knowledge of more DLSw 
switches is needed. I suspect the bulk of the traffic will be of the 
former (i.e dependent LU). Mind you Netbios makes a mockery of this.

I am not very keen on the idea of propagating known DLSw switches to 
other  DLSw in a similar fashion to Link State packets in OSPF (or NLSP 
for that matter).

Vendor Id

I like the vendor id and agree with David that inclusion of as much 
reasonable information, to ease troubleshooting and management, is 
generally a good idea. Including a phone number is even better - I can 
put someelse's  phone number in! (just joking).

I also like the ability to have vendor specific features (with the 
proviso that it doesn't get in the way of interoperability). This could 
be a way to deploy new features in the field prior to its inclusion into 
the RFC.

Base Set

Wayne posed the question of what in the existing RFC should be optional. 
I would like Netbios to be optional.

CANUREACH Suppression

I would like the ability introduced to optionally stop CANUREACH being 
sent to a DLSw  router (clearly the DLSw router in question can still 
send CANUREACHs).